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A CARD CUSTOMIZATION SYSTEM 

Field 

The present invention relates to the production of personalized 
5 cards and specifically, but not exclusively, for customising the 
images on a transaction card. 

Background 

There has been an increasing consumer desire for self- 
10 differentiation, particularly for differentiating mass-marketed 
personal items. This can be clearly seen in the recent popularity 
of customized mobile phone ring- tones and fascias. Indeed users 
of a particular mobile phone operator are able to download 
ringtones and occasional software updates, which might change the 
15 appearance of the display on a mobile phone. The internet has 
thus become a useful tool for users seeking to update their 
current products. 

Typically in the past, financial transaction cards, such as 
20 credit cards have remained un-personalised in appearance; perhaps 
due to anticipated difficulties in allowing a user to personalize 
the appearance of an item such as a credit card while also 
maintaining the overall security for the user's private financial 
information. • . 

25 

Developers of systems capable of applying personalized images to 
financial transaction cards of users consider it a high priority 
to provide secure technical means for providing information 
capable of associating user identities and / or account 
30 information with their personalized image. Such secure technical 
means are regarded as a pre-requisite and allow relevant 
information to pass from the card personalization service, i.e. 
the ASP (Application Solution Provider) , directly to the card 
issuer / production facility within integrated systems thereof 

- 1 - 



SUBSTITUTE SHEET (RULE 26> 



WO 2006/018624 



PCT/GB2005/003198 



(i.e. without compromising sensitive information relating to the 
user) . 

Such integrated systems effect the ability of card issuers to 
5 deliver web-based card design software to their clients, because 
the integration with the Application Solution Provider 
(Serverside Graphics) is too expensive, resource dependent and 
time consuming. For example, there- are many financial 
institutions that do not have the size or money to make the 
10 purchase of such integrated systems feasible, but who still wish 
to allow user the capability of customizing their images while 
allowing the user to make a secure application for a credit card. 

An aim of preferred embodiments of the present invention is to 
15 alleviate such issues and negate the necessity to set up complex 
and expensive integration's between the Issuer and the Application 
Solution Provider (ASP) . ■ 

An advantage of doing this is. that it will be possible to serve 
20 smaller card issuers and thereby broaden the applicability of the 
product . . 

Summary 

.According to one aspect of the present invention there is 
25 provided a method of enabling a user to make 'an application for a 
transaction card to be approved by a card issuer, the method 
comprising: connecting the user to a service provider arranged to 
enable the user to design an image to be displayed on the 
transaction card; generating a unique identifier corresponding to 
30 the designed image; and generating an application form having the 
unique identifier. 

According to another aspect of the present invention there is 
provided a method of enabling a user to make an application for a 
35 transaction card, the method comprising: connecting trie user to a 
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service provider capable of providing a service for enabling the 
user to "design" an image to be displayed on the transaction card; 
generating a unique identifier in the service provider . 
corresponding to the user image; and generating an application 
5 form in the service provider having the unique identifier. 

According to another aspect of the present invention there is 
provided a method of production of a personalized financial 
transaction card comprising: generating a unique identifier; 

10 recording a first version of the unique identifier in an 

application document, said application document processable by a 
card issuer to determine whether or not to issue a card to the 
user; allow the user access to a card personalization process; 
this process generating an image suitable for application on to a 

15 financial card; associating a second version of the unique 

identifier with this image most commonly through a login process 
before or after the image design process; processing the 
application document to determine a financial transaction card 
can be issued to the user; comparing the version of the unique 

20 identifier from the application document with the version of the 
identifier associated with the image to ensure a card is produced 
with the image and financial information relevant to the user. 

According to another aspect of the present invention there is 
25 provided a method of production of a personalized financial 
transaction card comprising: recording a first version of the 
unique identifier where this identifier is already known to the 
Issuer (such as Account Number and Sort Code or an Email address) 
in ah application document, said application document processable 
30 by a card issuer to determine whether or not to issue a card to 

the user; allow the user access to a card personalization process,- 
this process generating an image suitable for application on to a 
financial card; associating a second version of the unique 
identifier with this image most commonly through a login process 
35 before or after the image design process; processing the 
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application document to determine a financial transaction card 
can be issued to the user; comparing the version of the unique 
identifier from the application document with the version of the 
identifier associated with the image to ensure a card is produced 
5 with the image and financial information relevant to the user. 

According to another aspect of the invention there is provided a 
method of checking the unique identifier for validity using a 
Check Sum of that data which may be added to the login process on 
10 the service providers website; where this check sum is used to 
validate the other data entered using a predetermined algorithm 
known to the issuer and to the service provider. 



According to another aspect of the present invention there is 
15 provided a method of personalizing a financial transaction card 
by means of an internet service provider, comprising: causing the 
service provider to generate a unique identifier; recording a 
version of the unique identifier on an application document of 
the sort processed by card issuers to determine whether or not a 
20 financial transaction card should be issued to a user; allowing 
the application document to be processed by a card issuer,- 
providing the user access to image personalization software 
capable of producing a personalized image associated with a 
further version of the unique identifier; sending the image to a 
25 card production facility. 

According to another aspect of the present invention there is 
provided an internet service enabling a user to design an image 
for a transaction card, the service provider comprising: a design 
30 application capable of enabling the user, to design the image for 
display on the transaction card; and generation apparatus capable 
of generating a unique identifier corresponding to the designed 
image and of generating an application form having the unique 
identifier. 

35 

.4. 



SUBSTITUTE SHEET (RULE 26) 



WO 2006/018624 



PCT/GB2005/003198 



According to another aspect of the present invention there is 
provided method for manufacturing a card bearing an image 
designed by a user, the method comprising: generating a unique 
identifier to be associated with the image; and generating an 
application form for the card, which is capable of associating 
the unique identifier with a record of the user. 

List of Drawings 

Reference will now be made by way of example to the accompanying 
drawings, Embodiments of the present invention will now.be 
described. in relation to the accompanying drawings, 

Figure 1 shows a context for which a preferred embodiment 
of the present invention is implemented; 

Figure 2 shows a screen of website software with a standard, 
library of images; 

Figure 3 shows a login screen allowing users to login to 
the website; 

Figure 4 shows the capability to browse a user's own 
computer for images ; 

Figure 5 shows a new library including both the- user's 
images and a set of stock images; 

Figure 6 shows selecting a thumbnail image and 
manipulating the enlarged loaded image; 

Figure 7 shows the addition of frames for the image; 

Figure 8 shows the ability to return to a previous screen 
where the image and the frame can be seen; 

Figure 9 shows the final version of the credit card as 
customized by the user; 

Figure 10 shows an alternative, embodiment where a U1D is 
generated by the card issuer; 

Figure 11 shows the preferred embodiment where a UID is 
generated by the ASP; 

Figure 12 shows a web-based embodiment; 

Figure 13 shows a branch-based embodiment; 
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Figure 14 shows an embodiment where the application form is 
supplied by the card issuer through' the ASP to the user; 

Figure 15 shows an embodiment where the card issuer 
forwards a list of UlD's previously generated to the ASP . 
5 Figure 16 shows a flow diagram of . various modules for 

implementing a web-based embodiment; and 

Figure 17 shows a flow diagram of various modules for' 
implementing a branch-based embodiment. 

10 

Description 

Figure 1 shows a simple example of an embodiment of the invention 
which can be carried out across the internet represented by the 

15 cloud 2. The internet or World Wide Web is incredibly powerful in 
being able to connect and disseminate data to may different 
computers that are linked throughout the world. A plurality of 
users 4 are shown which have the capability of connecting to the 
internet; for example using a computer, modem and the relevant 

20 software. 

The users are able to access the websites of a plurality of card 
issuers 6, for example financial institutions or banks. The 
. concept of online banking has . already become widespread, where 
25 access to a user's private account details can be accessed by an 
approved login process . 

An Application Service Provider (also "Service Provider") ASP 8 
is also shown, which for example, may be a website server owned 

30 and operated by a third party which is capable of providing 
specific services to the users 4 and/or card issuers 6. 
According to one embodiment of the present invention, the ASP 8 
provides a design application 10 which allows a user to customize 
and/or design the images on a transaction card, for example a 

35 credit card. In a preferred embodiment, the design application 10 
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is for example a computer program run on a dedicated server which 
allows the design and editing functionality required by the user 
to customize an image for a credit card. It should be 
appreciated that the design application can be located either 
5 within the ASP itself or accessed from a remote location (i.e. a 
remote server or website) . 

Several screen-shots revealing how such a credit card design 
website might operate in a series of steps as shown in Figures 2 

10 to 9 . Figure 2 shows a first screen with a standard library of 
images assigned to the particular card issuer that is using the 
credit card design website, on the left of the screen.' Figure 3 
shows a screen allowing users to log in so that a username and 
password (and/or other information such as account number and 

15 sort code or email address, or a coded unique identifier - UID) 
can be used to identify the user and the card they design. In 
Figure 4, the upload allows the user to browse' his or her own 
computer for images to upload. Figure 5 shows a. screen with a 
new library including both the user's images and a set of' stock 

20 images. In the screen of Figure. 6, by clicking on the thumbnail 
image on the left hand side, the bigger but still web-optimized 
image is loaded. At this point it can be scaled, flipped, 
rotated, or undergo other manipulations; and the card details can 
be viewed or hidden. In the screen of - Figure 7., frames can then 

25 be added. These are for example Flash (.swf)- files that allow 
transparencies. Again they can be flipped, scaled, rotated, or 
undergo other manipulations; and the card details can be hidden. 
In the screen of Figure 8 , by clicking a button or on the Step 1 . 
tab, the user can return to a previous screen. At this point the 

30 image is shown as "live" but the frame can be seen as well. The 
screen of Figure 9 shows the final version of the personalized 
credit card before it is sent off to the back end software to be 
manufactured. 
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In certain systems such as that disclosed in PCT/GB2004/000626, a 
unique identifier (UID) is issued by a card issuer and used by 
the to ensure each card produced bears the image and personal 
information of the relevant user. The UID is retained by the card 
5 issuer and associates or links a user to his/her personal account 
details. 

This technique a number of problems. First, the cost of 
integrating the systems to pass over the UID in real time with 

10 the user and, the system changes required to enable the storage 

of the UID, has substantial cost. Second, the user must return to 
the card issuers website to get a new UID if the initial one is 
lost (by a network failure or session timeout for example) . Third, 
there is very often not a shared database between the website and 

15 the mainframe / embossing elements of the Issuers IT systems. 

In a preferred embodiment according to this invention the UID for 
the images that are produced by the design software 10 are 
created by the ASP 8. This avoids the costly implementation costs. 

20 This UID is used to associate a user (or user account information) 
with their personalized and/or customized image. It is a feature 
of preferred embodiments that the ASP design software 10. 
generates and issues a UID associating each image to the relevant 
user, and sends this UID in one form or another to the relevant 

25 user. From this point forward the design/image is always 
associated with the user by this identifier. In another 
embodiment, the UID could be assigned to the user later in the 
"web experience" if their information was held as a Session 
Variable before this point but this would not substantially 

30 change the process. 

It should be noted that the UID can be expressed in many 
different ways. For example, the UID may be numerical, alpha- 
numeric or coded in some other machine-readable form, for example 
35 a barcode . 
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Irrespective of where it is generated, a UID may be embedded in 
an application form for a transaction card or a similar document. 
Such an application form may be provided by the card issuer 
5 and/ or the ASP, as will be explained below. Alternatively, or in 
addition, the UID may be embedded within the image itself, and 
the image applied to the application document, wherein decode 
circuitry is able to recover the UID from the image. The 
association of the UID with the application form ensures that, 

10 after the form has been completed and returned for processing by 
the card issuer, the cards generated for the user in question 
bears the relevant personal account information and that users 
personalized image. In fact, the association with the application 
form enables the card manufacturing process to source individual 

15 personalized images prepared by users (usually in groups of 

images) for application to cards which will also bear the relevant 
individual account information. 

Indeed, PCT/GB04/003537 from which the present application claims 
20 priority, describes a system where a credit card. embossed with 
the image (s) designed by a user, and having a UID embedded 
therein, can be read without explicit indication of the user. 
Thus there is still security in that a card issuer may entrust 
the card-making facilities to a trusted card manufacturer by 
25 providing them with the relevant decode circuitry (and/or 

including the relevant decode algorithms) to be able to recover 
the UID from the image to be printed on each card. Figure 10 
shows an example of this. 

30 Figure 10 shows an embodiment where the UID is generated by the 
card issuer, as opposed to preferred embodiments of the invention 
where the UID as generated by the ASP, but it is still useful in 
illustrating aspects of the present invention. Specifically, the 
card issuer might have in-house card manufacturing facilities or 
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instead make use of a remote trusted card, manufacturer 11 
(further shown in Figure 1) . 

Figure 10 shows such a system, including a card manufacturer 
5 having facilities 311 and 313, a card issuer 301 and an ASP 303. 
It should be appreciated that the facilities 311 and 313 may be 
owned and operated by the same or different parties either on 
site or in remote locations. Moreover, many of the features 
shown in Figure 10 as being associated with the card manufacturer 

10 might be associated with one of the other institutions. For 
example, the read/write module 318 is an example of decode 
circuitry which is able to read the OID (Optical identifier) , 
recover the UID embedded in the image, and/or write the recovered 
UID into the cards magnetic strip, thereby making the UID of each 

15 card magnetically readable by a card finishing machine 319. 

In figure 10 a card issuer 301 passes a UID 302, for each 
cardholder who will be personalizing their card's appearance, to 
a card graphics hosting facility 3 03. 

20 

The card graphics hosting facility 3 03 associates 3 06 each 
cardholder's digital identifier with the cardholder's completed 
card design digital image, and stores them in a card graphics 
warehouse module 3 08 which may be a near- line image storage 

25 facility. In one embodiment, the card graphics hosting facility 
303 associates 306 the UID with its corresponding image by 
converting the digital identifier into an optical format, using, 
for example, a barcode, text, microdot, microtext, invisible ink, 
or other technique; and embedding the optical -format identifier 

30 (OID) as part of the digital image to be applied to the card; for 
example by printing the OID into the image itself . The OID may 
also be printed in two or more different optical formats, or 
multiple times in the same format, so that it can be read in the 
event of a mis -scan. 

35 
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The card graphics warehouse 3 08 passes the digital images with 
embedded OID's 312 to a card graphics print server 314 at a card 
manufacturer 313. The card graphics print server 314 may be, for 
example, an offline short-term image storage facility, designed 
5 to optimize images for the associated printer. Because the UID's 
have been embedded optically in the digital images, only the 
images 312 need to be passed to the card manufacturer 313, 
without a need for the UID's to be transmitted separately. The 
digital image with embedded optical OID 315 can then be passed to 
10' a digital printer 316, which simply prints all of the cards whose 
images are passed to it by the print server 314. The digital 
printer 316 may be a machine that is Pant one -compliant and- prints 
at over 800 dpi; that can lay down logos, brand marks, OID's, and 
■ card designs in a single process, both rapidly and economically. 

15 

Next, the printed card 317 with embedded OID in its printed image 
is passed to a read/write' module 318, which reads the OID of each 
card and encodes it into the card's magnetic stripe, thereby 
making the UID of each card magnetically readable by a card 

20 finishing machine 319. The cards with magnetic UID's 320 are 
shipped through the conventional channels from the card 
manufacturer 313 to the card finishing facility 311. A card 
finishing machine 319 (such as a Datacard 9000 or other machine) , 
can then read each card's magnetic UID and use it to associate 

25 the correct image-printed card with the associated cardholder's 
financial information, as provided over link 310. A finished 
card 321 can then be produced, which has a user's financial 
information as well as a personalized appearance. 

30 There are a number of advantages to the embodiment of Figure 10. 
First, because the UID's are optically embedded in the digital 
images 312, there is no need to send the UID's separately to the 
card manufacturer 313. This means that' only one file type (the 
digital image file type) needs to be passed to the card 

35 manufacturer 313, in one direction; thus, the dedicated line for 
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transmitting data 312 can be easily locked down in a firewall. 
In addition, the process of Figure 10 makes it easier for a card 
issuer 301 to request that a card be re-issued; the card issuer 
301 simply sends the UID of the card to be re-issued in the same 
5 list 3 07 of digital identifiers that is sent 309 to the card 
finishing facility 311. 

Figure ll shows a basic diagram of a preferred embodiment of the 
present invention. One of the differences over the embodiment of 
10 Figure 10, is that in the preferred embodiment, the UID is 

generated in the ASP and not by the card issuer. . Figure 10 has 
been simplified in several respects but Figure 10 remains useful 
in describing the functionality that can still be used in the 
preferred embodiments. 

15 

Specifically, the functionality of the card graphics hosting 
facility 3 03 of Figure 10 is similar to the. ASP 8 of the 
preferred embodiment shown in Figure 11 in that both allows a 
user to customize the design or images of 'a credit card over the 
20 internet . 

However, whereas Figure 10 shows different functionality 
representing the card manufacturer 313- and the card finishing 
facility 311, such card processing functionality is not shown in 
25 Figure 11. Indeed it may be assumed that such processing 

functionality is performed by the card issuer 6 themselves. It 
should be appreciated that an alternative embodiments, such 
processing functionality can be assigned to third parties, which 
are trusted yet distinct from the card issuer. 

30 

Such simplifications make it useful in emphasizing that in the 
preferred embodiment of Figure 11, the UID is generated within 
the ASP and provided back to the user along line 102 after the 
design has been established via line' 100. The UID is preferably 
35 provided as part of or embedded in a document provided to the 
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user along line 102. Typically, the document is an application 
form for a personal transaction card, such as a financial 
transaction card or a loyalty card, or the like. 

5 Specifically, Figure 11 shows a user 4 which is able to 

communicate separately with an ASP 8 and a card issuer 6. The 
user 4 is able to visit the website of the ASP 6 and customize 
the image (s) of a credit card online. In creating/modifying an 
image, a UID is automatically generated by the ASP and is 
10 associated with that image. A document is then created which 
includes the generated UID and is sent back to the user. 

This document may be in paper or electronic form. The document 
can for example be an application form for a new credit card with 
15 a particular bank. 

Figure 12 shows a web-based embodiment where the credit card 
application form is in an electronic form and can be received, 
completed and sent by the user 4 to the card issuer in electronic 
20 form. 

Figure 13 shows a branch-based embodiment where the credit card 
application form is in a paper form. In this embodiment, this 
application form has a "bangtail" component which can be detached 
25 as will be explained in more detail below. The generated 

application form can be provided by a bank for collection by a 
user and completion or alternatively, the generated application 
form can be sent directly to the user who can submit the 
completed application form to the bank. 

30 

In another embodiment, the application form can be transferred to 
a processor or production center of a card issuer. For example, 
the card issuer will receive the application form and process it 
within its systems, using the embedded UID to match the user's 
35 financial account information with the relevant 
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personalized/ customized image. A database or table can exist 
within the card issuer system which contains cross-reference 
information relating each UID with the user's corresponding 
private account . 

5 

Preferably the embedded UID is machine read as part of a. card 
production process and a computer performs the matching to 
produce a card with a given user's personalized / customized 
image and relevant account details. However, the UID may also be 
10 embedded as an OID, in which case the production centre 

(processor) of a card issue will need to have a read/write device 
of a similar nature to the one shown in Figure 10 for recovering 
the UID from the read OID. 

15 The process may begin with a user arriving at a branded URL (such 
as http://issuer.asp.com). This URL will allow the ASP to select 
the correct branding for the look and feel of the site and for 
the financial card templates that the user will see. Thus a 
number of card issuer websites for a number of distinct card 

20 issuers can be hosted using a single web interface. By assigning 
specified default criteria to the URL forwarding process or by 
other parameter setting means the webserver is able to 
differentiate between the different card issuers and thereby 
assign their various branding, template and application form 

25 elements. In this way, the ASP is able to provide an interface 
capable of supporting a plurality of card design websites 
corresponding to a variety of different card issuers. Thus the 
user is able to select which URL to access (i.e. website hosted 
by the ASP corresponding to a particular card issuer) . 

30 

The application form will be selected from a number of such forms 
based on the URL (or other identifier) that the user enters 
through. Thus a number of application forms for a number of card 
issuers can be hosted using a single web interface. 

35 
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Alternatively,' the ASP may have a single URL which the user is 
able to log onto and from those login details, the ASP is able to 
redirect the user to the corresponding application form (or URL 
bearing that application form) which is associated with the 
5 relevant card issuer. In both cases, the application forms are 
' hosted by the ASP on behalf of the card issuer, but are separated 
from the card issuer and/or the website of the card issuer. 

The user is now able to design their card using the online card 
10 design software and utilizing a number of tools such as image 

galleries, a variety of different card templates (different fixed 
elements to the card) , and a variety of different' frames or 
different designer types. Designer types may include the ability 
to move, size, rotate and flip images and /or logos and /or they 
15 may allow the addition of text on to the card for example as 
shown by the screenshots of Figures 2 to 9 described above. 
Various other functions associated with the ASP are for example 
shown in relation to steps 2a and 2b in the embodiments of Figure 
14 and Figure 15 respectively, which will be discussed in more 
20, detail later. 

After the issuer has finished their design, the next step in the 
process is to output a UID from the ASP, which is associated with 
a particular user, which is in turn associated with the image 
25 that has just been designed by that user. A data table is held in 
a location accessible to the ASP (i.e. either within or remote 
from the ASP) so as to associate the user with their image by way 
of the UID. 

30 The next step in the process is that the ASP is able to generate 
the relevant application form with the UID embedded into it, 
which can then be presented to the user 4 . This application form 
might be sent and presented electronically to the user as an MS 
Word document or an Adobe Acrobat (PDF) document for example. The 

35 user is able to compete the form electronically and submit it to 
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the relevant card issuer 6 electronically, for example using the 
web-based form shown in Figure 12. In the embodiment of Figure 
12, the application form comprises a UID which in this case is 
simply a humanly- readable alpha-numeric sequence 120. The 
5 application form can also comprise for example an attached 

picture of the design 122 of the credit card created by the user. 
Thus, the application form may or may not include a copy of the 
image that has been generated. The image may be included as a 
marketing tool . The user is also able to complete the form by 
10 filling in his personal details 124.. 

It should be appreciated that in another embodiment, for security 
reasons, the personal details 124 might be left off the form (in 
which case the ASP would need to contact the card issuer 
15 separately to provide the generated UID associated with each 
user's design) . In this way, the card issuer is then able to 
match up the received- UID with the relevant user's account 
details . 

20 In different embodiments, the UID may be embedded as either text, 
barcode, machine- readable or humanly- readable form. 

Alternatively, the user can print-out paper copies of the 
application form, which was received in electronic form. The 
25 user 4 then completes the form and can then either post it or 
take it to the relevant card issuer (or bank branch) directly. 
Thus, the user at this stage may print the application form and 
complete it. 

30 In another embodiment, the form may be provided to the user as a 
hard copy. Thus, the ASP 8 can send the application form to the 
user, to an email address, to a card issuer branch, or to some 
other remote location for completion at a later date. For 
example, the form can be emailed from the ASP to a branch of a 

35 card issue who can then print-it off in hard copy and wait for 
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the relevant user to come into the branch requesting the 
application .form or it can be sent to the user in the post. 

Thus, the user is able to fill in the application form and either 
5 send the application form into a form processing centre of the 
cardissuer by post (or another suitable transmission means) or 
physically to go to an card issuer's branch themselves . The 
transfer of the application form from the user 4 to the card 
issuer 6 may in some embodiments be completely electronic and/ or' 
10 automated. 

In one embodiment the system may incorporate a technology, for 
example one developed by Adobe systems that allows the user to 
enter 1 details in an electronic environment (on PDF software for 

15 example) and for a barcode to be generated within the same 
document that reflects the information input. Thus when the 
information is input and printed (including the UID) the . 
application details and UID can be scanned using a barcode reader 
by the card issuer 6 to obtain all of the information in the form 

20 - thus avoiding the cost and errors associated with data re-entry. 

In another embodiment of the invention, the user 4 is forwarded 
after the design process, to the card issuer's website (with the 
associated UID also being passed) and wherein the user is 

25 subsequently able to fill in a form either online or offline; 

However, this embodiment is more costly as - there is at least some 
integration cost for the card issuer 6 and the ASP 8 . This allows 
for a similar process as that if the form is hosted by the ASP. 
However, the advantage of this embodiment is that it allows the 

30 card issuer 6 to integrate the card design process with their 
standard on-line card application or card management system. 

In a preferred embodiment of this method the user would be 
transferred to the card issuers website by means of a hyperlink, 
35 for example in HTML (Hyper Text Markup Language) , with the UID 
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stored in the URL. To avoid security breaches this URL would be 
encrypted by means of a digital signature which may include a 
timestamp . 

5 Figure 14 shows such an embodiment where the application form is 
supplied 142 by the card issuer 6 through the ASP to the user 4. 
The UID is either embedded in the application form or passed 
along with it, for example with the UID stored in the URL. 

10 At step S4, the user fills in the application form and then may 
return it to the card issuer 6 electronically, or can print off 
the application form in hard copy and return it by post or 
directly depositing it at the relevant branch of the card issuer 
6. By allowing the user to print-off the application and deliver 

15 it offline, it is possible to overcome the aforementioned 

disadvantages associated with a fully integrated system, while 
still retaining security in having an embedded UID in the 
application form. 

20 At step S5, the card issuer 6 processes the application form in 
its standard manner but additionally sends the UID with the 
embossing records to the processor 140 at step S6. This UID may 
be included in the embossing record or sent as a cross-reference 
table or the like. 

25 

Once the processor 140 receives the embossing record at step S7, 
it can request the image from the ASP 8 at step S8 . This process 
could be done in advance of receiving the embossing record but 
would be less efficient as many images would remain unused. The 
30 image and the embossing record, which both contains forms of the 
UID, can then be associated and printed using standard industry 
printing and embossing systems such as those provided by Datacard 
and explained in relation to the Figure 10 embodiment. 
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A further embodiment is for the ASP to email the user at the step 
S3 of image checking to see if the card designed by the user is 
rejected. This will allow the user to re-enter the site (using 
the original UID or a new one) to redesign the card. 

5 

If however the image has been rejected at the step. S3 of image 
checking then the ASP will respond with a code to show why the " 
image has been rejected and the user may be sent a standard card 
design by the Processor 140. 

10 

Another embodiment of the invention is shown in Figure 15 wherein 
the card issuer 6 may forward a list, or database, of UID's 
previously generated by the card issuer to the ASP. The card 
issuer would hold this list in reference to the users financial 

15 account details. The ASP would hold only the list of UID's. In 

this embodiment the ASP would request that the user log in to the 
website as shown by step T4 using the UID, or information that 
will identify the UID, and thereby associate the user with a UID. 
The user would again be asked to design the card and then, at 

20 step T5, offered an application form to print out or forward as 
with the Figure 14 embodiment. The difference being that in the 
embodiment of Figure 15, the UID, once returned to the card 
issuer, could then be associated with existing account details. 
In this way the invention could be used to accommodate pre- 

25 existing accounts . 

In a further embodiment the UID used in for example the branch 
example might be or be derived from the Account Number and Sort 
Code or an email address or other personal information that is 

30 already known to the issuer. In order to avoid the danger that a 
third party may enter another customers information it should be 
possible to use a shared security key that will for example run a 
hash on the information that' will be given to the user in branch 
(thereby ensuring that the information is secure) which the user 

35 can take away with them before logging in to the service 
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providers site. This will ensure that: 1. the information is 
secure (it has been obtained from a bank representative) ; 2. that 
the issuer need not retain any new information as it is already 
known to them (and may even be present in the embossing record) 
5 so few IT changes are required; 3. the information that is 

entered in to the website can be checked against the hash data to 
ensure that it is valid.. 

A further aspect of the invention is that, in order to avoid the 
10 mis-input of the UID's by staff associated with the card issuer, 
in the preferred embodiment there would be a "self-verifying" 
element in the UTD. In essence this will mean that the UID has an 
inherent checking capability that will check the integrity of the 
rest of the UID. For example, the check might be that the final 
15 digit of the UID is equal to the final digit of the sum of the 

rest of the UID. Thus, 1292 could be a UID where 2 is. the carried 
over check on the rest of the ID (1+2+9 = 1 [2] ) . There are a 
number of well known algorithms to achieve this type of check 
process. 

20 

In a further embodiment the UID's (or range of UID's) are pre- 
generated by either the ASP or the card issuer and supplied to 
the other party. The card issuer will use these UID's to generate 
a set of paper-based application forms. These forms will be 

25 distributed through traditional paper-based means such as through 
the bank branch or other marketing processes . The forms will have 
two sections as shown in Figure 13 before. In the first section 
13 6 there will be a normal application form with the UID embedded 
134 - either as: a printed number (as shown in Figure 13), a 

30 barcode, or other machine -readable form (for example a digital or 
binary sequence) . The second section 130 will be a rip-off strip 
(a "bang-tail") that the user can take-off the main application 
form. The bang-tail 130 contains the UID of the main application 
form and, according to certain embodiments, also contains the 

35 website address of the ASP 8 . 
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At the point of application for the card, the user fills out 
section 13 6 and typically will leave it with the card issuer, for 
example with a clerk or agent in the branch, but retains bang- 
5 tail section 130. With section 130 the user is able to access the 
ASP website and use the UID printed on the bang-tail to log- in to 
ensure that the number on the application form and the image 
created can later be married up. The log- in process can occur 
before or after the card has been, designed. By using different 
10 URL's and UID's it is possible for the ASP to determine which 

card templates and branding information - such as stock images - 
should be shown to a particular user. 

In an further embodiment the card issuer may generate the UID's 
15 and need not supply them to the ASP in which case a self- 
verifying UID would be a sensible option to select to ensure that 
the UID is valid. 

In a further embodiment the card issuer generates UIDs, or 
20 requests UID's from the ASP, on an ad-hoc basis whenever an 
additional application form is requested. 

Figure 16 provides a flow diagram showing examples of various 
modules that are able to implement the web-based embodiments 
25 associated with Figure 12 . 

Specifically, the card issuer 6 is shown to have the following 
modules: a card issuer website 160, a web-based campaign 161, a 
direct mail campaign 162, an application form delivery module 167, 

30 an application form processing module 168 and an image checking 

module 169. The processor functionality 140 is shown to comprise: 
a card bureau 170, a print module 171, and a card sending module 
172. The ASP 8 is shown to comprise: a marketing page 163, an 
image design interface 164, a terms and conditions unit 165, and 

35 an application form module 166. 
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Figure 16 shows that the website module 160 of the card issuer 6, 
which for example provides information on the various products 
provided by the card issuer, is interconnected to a web-based 
5 campaign module 161 and a direct mail campaign module 162 . Both 
modules being associated with marketing such products to users, 
but wherein module 161 does so by using the web or email, whereas 
module 162 does so by using the standard postal service. 



10 The ASP 8 is shown to step through a sequence of the modules 163, 
164m 165 and 166. And each connection between the sequences 
provided over an SSL (Secure Socket Layer) in a preferred 
embodiment, which allows secure access to validated users. So 
initially, a user is able to access a marketing page provided by 

15 the ASP which can provide a cover page and a layout of the 

various service offered by the ASP. The user is then able to 
select the desired service, or for example, the relevant image 
design interface 164 which could for example provide the design. , 
software but presented with the specific branding or themes 

20 associated with the relevant card issuer (or bank) selected by 
the user. A terms and conditions module 165 is then able to set 
out the terms for using the ASP website and/or parameters 
associated with the card (i.e. requested credit limit). Such 
terms and conditions can be enclosed in the application form 

25 which is generated by the application form module 166. 



The application form module 166 also generates a UID and this is 
embedded in the generated application form along with a copy of 
the image (s) designed by the user for the card. The application 
30 form then being sent to the card issuer 6- shown as route A in 
Figure 16. 

For route A, the application form is sent from the ASP 8 to 
module 167 of the card issuer 6, which indicates that the 
35 application can for example be sent: electronically (for example, 
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over the web) , hand-delivered directly by walking into the branch 
or by normal post . The application form is then processed using 
the module 168 which might for example have a read/write device 
that is capable of retrieving the UID in the application form, 
5 particularly if embedded as an OIR in the image itself. Module 
168 sends the embossed records and recovered UID to the processor 
140, specifically the card bureau module 170. 

In route B, the image is sent from the ASP 6 to an image checking 
10 unit 169 (described earlier) which checks whether the image 

designed by the user for the card is suitable. If not, the user 
is able to re-enter the site using the existing UID associated 
with the image, or alternatively a new one required to redesign 
the card. The image checking unit is able to communicate with the 
15 card bureau module 170 of processor 140 using SSL and can request 
from the bureau module 170 if the designed image is supportable 
by the functionality of the processor 140 (for example, has the 
appropriate printing apparatus for printing the user's desired 
image) . If it is supportable, the image is sent to the card 
20 bureau module 170, whereas if it is not, a standard default image 
is sent to the card bureau module 170. 

After receiving the design at the card bureau module it is sent 
to the print module 171 having the appropriate printing apparatus 
25 for printing and embossing the designed image (s) onto the card. 

The card sending module 172 represents that the finished physical 
card is then sent to the user 4. 

Figure 17 provides a flow diagram showing examples of various 
30 modules that are able to implement the branch-based embodiments 
associated with Figure 13. 

Some of the modules are the same as referred to in Figure 16 and 
as such the same reference numerals are used. Figure 17 differs 
35 in that the user enters the branch which already contains an 
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application form having an embedded UID shown by the modules 180 
and 182 respectively. 

In use, the completed application form - 182 - is processed by 
5 processing module 168, which for example might contain 

read/circuitry able to recover the embedded UID. The image 
corresponding with the UID can then be generated by the user - 
using the same UID as the service providers website 164 - to log 
in to the service provider 190. To do this the user tears off the . 
10 bang-tail section 130 of the application form as shown in Figure 
13 and is able to then separately access the ASP 8 in order to 
generate the relevant design to be used on the card. For example, 
the bang-tail section provides a certain URL 

"www.internationalbanking.com/photocard" which will take the user 
15 to the relevant login page or server hosting the design software 
for the relevant bank. The login process being indicated by the 
login module 190 may for example involve typing in the UID which 
is also printed on the bang- tail module. The user can than 
create the required image which is then checked by the image 
20 checking unit 169 to see if it is supported. If yes, the image 
is sent to the card bureau 170 of the processor 140, but if not, 
a standard image which is supported is sent to the card bureau 
170. 

25 The embossed record which might include client information, the 
image and the UID are then sent from the module 160 to the card 
bureau module 170 of the processor module 140. 

Thereafter, the card is printed and sent to the user as explained 
30 in Figure 16. 

There are a plurality of advantages that flow from embodiments of 
the present invention: 
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1) The embedding of a UID with in an application form that 
corresponds to the image that the user has designed, which allows 
for the advantage that the UID is passed in a non-technical 
manner from the service provider to the Issuer and therefore 

5 requires no technical integration of the two systems 

2) The embedding of a version of the image within the. 
application form has the advantage that the user is more likely 
to fill in the form as the form has personal resonance. 

10 • 

3) The generating of the UID to be assigned to the users image 
has the advantage that the Issuer and the Card Designer need not 
be technically linked. 

15 4) The assignation of branding elements and application' forms to 
a variety of different URL or website access points, which has 
the advantage that multiple issuers can be maintained on a simple 
site by only changing simple branding elements . 

20 5) The hosting of a plurality of application forms associated 
with corresponding card issuer's on a website has the advantage 
that a single design interface can be used to apply to a 
plurality of card issuers . 

25 6) The branch-based embodiment which makes use of a tear-off 

strip with a UID associated with the original application form to 
enable personalization to occur after the application and from a 
different geographic location if preferred. For example, one can 
take the bang- tail to an internet cafe to personalise the image. 

30 This means that the acquisition (of new card holder) benefits of 
personalization of financial cards is not missed on in-branch 
statements of interest in the cards. The user is signed up for 
the product first - and then given access to the site. 
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7) The embodiment wherein there is a URL' link after the card 
design process which redirects the user back to the card issuer's 
(or partner) website and passes the UID associated with the image, 
which has the advantage of allowing the partial integration of 

5 the design process into the standard online application processes 
of the bank. 

8) By using previously known information to identify the user in 
the Branch based scenario the Issuer may be able to avoid any 

10 substantial changes to their present IT system as they will not 
need to i . integrate with the service provider or ii . Make 
changes to saving new information in their mainframes or iii. 
(Potentially even not) make changes to their embossing records. 
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CLAIMS : 

1. A method of producing a personalized transaction card of 
the type approved for issue by a card issuer, the method 

5 comprising: 

connecting the user to a service provider arranged to 
enable the user to personalize an 'image to be displayed on the 
transaction card; 

generating a unique identifier corresponding to the 
10 personalized image; and 

generating an application form for • processing by a card 
issuer and comprising the unique identifier. 

2. The method according to claim 1, wherein- the unique. 
15 identifier is generated by the service provider. 

3. A method according to claim 2, wherein the application form 
comprising the unique. identifier is supplied to the user by the 
service provider. 

20 

4. The method of claim 1., wherein the application form 
comprising the unique identifier is supplied to the user by a 
card issuer or agent thereof, other than the service provider. 

25. 5. The method of claim 4, wherein the application form is 
supplied by the card issuer and further comprises a tear-off 
section which includes' the unique identifier, or personal 
information from which the UID can be derived, and access data 
relating to the web site of the service provider,' and wherein the 

30 user is able to detach the tear-off section and use the tear-off 
section to provide logon information at the web site of the 
service provider. 

6. The method of any preceding claim, wherein the personalized 
35 image comprises one or more selected from: an image prepared by 
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the user, an image edited by the user, an image selected by the 
user, a plurality of images, one or more of the aforementioned 
together with text . 

5 7. The method of any preceding claim, wherein the unique 
identifier is in a humanly- readable form. 

8 . The method of any of claims 1 to 7 , wherein the unique 
identifier is in a machine -readable form. 

10 

9. The method of any preceding claim, wherein the application 
form further comprises the personalized image. 

10. The method of claim 9, wherein the unique identifier is 
15 embedded in the personalized image as an optically readable 

identifier. 

11. The method of claim 10, wherein the card issuer is capable 
of receiving and decoding the optically readable identifier so as 

20 to recover the unique identifier 

12 . The method of any preceding claim wherein the application 
form is in a paper form. 

25 13 . The method of any of claims 1 to 11 wherein the application 
form is in an electronic form. 

14. The method of any preceding claim, wherein the user is 
connected to the service provider over an internet connection. 

30 

15 . The method of any preceding claim, wherein the service 
provider is a separate entity from the card issuer and provides a 
plurality of interfaces corresponding to different branding 
templates, each branding template being associated a different 
35 card issuer. 
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16. The method according to claim 1, wherein the unique 
identifier is generated in the service provider and wherein after 
personalizing the image, the user is able to be automatically 
5 redirected to the card issuer via the service provider for 
completing the application form online. 



17. The method of any preceding claim, further comprising the 
card issuer: receiving the completed application form; and either 
10 checking in a database whether the received unique identifier 

corresponds to a customer account for the user; or processing the 
application form; 

producing the transaction card with the personalized image 
. applied to it and sending the transaction card to the user. 

15 

18 . A method of enabling a user to make an application for a 
transaction card, the method comprising: 

connecting the user to a service provider capable of 
providing a service for enabling the user to determine a 
20 personalized an image to be displayed on the transaction card; 

generating a unique identifier in the service provider 
corresponding to the user image,- and 

generating an application form in the service provider 
comprising the unique identifier. 

25 

19. The method according to claim 18, wherein the user receives 
and complete the application form separately from the card issuer 
and submit the completed application form to the card issuer. 



30 20. A method of production of a personalized financial 
transaction card comprising: 

generating a unique identifier; 

recording a first version of the unique identifier in an 
application document, said application document processable by a 
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card issuer to determine whether or not to issue a card to the 
user; 

associating a second version of the unique identifier with 
an image desired by the user to personalize the financial 
5 transaction card; 

processing the application document to determine a 
financial transaction card can be issued to the user; 

matching the version of the unique identifier from the 
application document with the version of the identifier 
10 associated with the image; and 

producing a financial transaction card bearing the personalized 
image and financial information relevant to the user. 

21. A method of producing a personalized financial transaction 
15 card by means of an internet service provider, comprising: 

generating a unique identifier; 

recording a version of the unique identifier on an 
application document of the sort processed by card issuers to 
determine whether or -not a financial ■ transaction card should be 
20 issued to a user; 

allowing the application document to be processed by a card 
issuer; 

providing the user access to image personalization software 
capable of producing a personalized image associated with a 
25 version of the unique identifier from the application document; 
and 

sending the image to a card production facility. 

22. A method as in claim 21, wherein software of the internet 
30 service provider generates a financial a transaction card 

application document for completion by users, the application 
document comprising said version of the unique identifier. 

23. A method as in claim 22, wherein the software of the 
35 internet service provider comprises a selection of financial 
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transaction card application documents, each relating to a 
different card issuer, from which the user may select. 

24. A method as in claims 22 or 23, wherein a version of the 
5 unique identifier is recorded on the or each financial 

transaction card application form selected by the user. 

25. A method according to any preceding claim, wherein the 
unique identifier comprises or is derived from personal 

10 information relating to the user. 

26 . A method according to any preceding claim, wherein the 
unique identifier comprises or is derived from one or more 
selected from: account number; sort code; postal address; and 
15 email address. 

27. A method according to any preceding claim, wherein the 
unique identifier comprises or is derived from information held 
by the card issuer before the transaction card is applied for. 

20 

28. A method according to claim 25, wherein the unique 
identifier is generated by the card issuer and the service 
provider verifies the unique identifier by re-determining it from 
the personal information used by the issuer to generate it. 

25 

29. A method according to any preceding claim, wherein the 
unique identifier is applied to the transaction card application 
form after the image is designed. 

30 30. A method according to any preceding claim, wherein the 

unique identifier is applied to the transaction card application 
form before the image is designed. 

31. A computer program of facilitating a method according to 
35 any preceding method claim. 
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32. A computer program according to claim 31, recorded on a 
carrier. 

5 33. An internet service provider site enabling a user to design 
an image for a transaction card, the service provider comprising: 
a design application capable of enabling the user to design 
the image for display on the transaction card; and 

generation apparatus capable. of generating a unique 
10. identifier corresponding to the designed image and . of generating 
an application form comprising the unique identifier. 

34. The service provider of claim 33 comprises a computer 
arranged to execute .a computer program in response to 

15 instructions received from the user for designing the image. 

35. A method for manufacturing a card bearing an image designed 
by a user, the method comprising: . 

generating a unique identifier to be associated with the 
20 image; and 

generating an application form for the card, which is 
capable of associating the unique identifier with a record of the 
user. 

25 36. The method of claim 35, wherein the step of generating a 
unique identifier is performed before the image is designed. 

37. The method of claim 35, wherein a step of applying for a 
card is performed before the image is designed. 

30 

38. The method of claim 35, wherein the unique identifier is 
generated in a service provider in response to a request from the 
user which has logged onto the service provider, wherein the 
generated unique identifier will be associated with the image to 

35 be designed at a later time. 
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39. The method of claim 35, wherein the step of generating a 
unique identifier is done after the image is designed. 

5 40. The method of claim 35, wherein the step of generating an 
application form capable of associating the unique identifier 
with a record of the user is performed after the image is 
designed. 

10 41. The method of claim 35, wherein a step of applying for a 
card is performed after the image is designed. 
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